ci: migrate to manifest config #173
Conversation
|
Thanks for looking at this. One point of concern: at least the last time I migrated to a manifest config, it ended up changing the tag name release-please used, which then disrupted the next release. We can mitigate that affect by setting a |
|
Thanks @nzakas, hopefully i've done this right. I've added the sha for the commit just before 3.0.1 as it states to do in the release-please docs. |
|
The docs say:
We actually want the commit for 3.0.1, because we want the next commit after that to be included. |
.github/release-please/mainfest.json
Outdated
| @@ -0,0 +1 @@ | |||
| {".":"3.0.1", "bootstrap-sha": "877a1a20cc5a3505c146ffff027c495794495f7f"} No newline at end of file | |||
There was a problem hiding this comment.
bootstrap-sha needs to be in the config file rather than here.
|
Whoops! Have moved to correct location and changed sha as requested. |
nzakas
left a comment
nzakas
left a comment
There was a problem hiding this comment.
LGTM, thanks! We'll see what happens in the next release. 😄
2 participants
This PR migrates the release-please workflow to the latest version, moving to a manifest-based config like eslint-community/eslint-plugin-n and eslint-community/eslint-plugin-promise.
.github/release-please/config.jsonwas lifted directly from these.Permissions have been moved to the job-level rather than workflow-level, and the release-please steps and npm publish steps split into their own respective jobs, to ensure each have only the permissions they need.
This will stop the release-please workflow from consistently failing as it currently does.